Service Function Chaining (SFC) is a mechanism in which packets of a flow or session pass through an ordered set of service functions (SFs) (i.e., network elements) for delivery of end-to-end services in compliance to policy and regulatory requirements. Software defined Network (SDN) or Network Function Visualization (NFV) enables dynamic service chaining, in which incoming packets are classified and mapped to the appropriate SFC based on one or more of the following factors including the access type, traffic type, subscriber identity, subscriber category (residential, enterprise, and the like), transport protocol, and the like. Sharing of metadata across SFs as part of the packet headers is done to avoid re-classification after every hop (to determine the next hop) and sharing relevant information (for example, subscriber identity). After each SF in the SFC performs its actions, the packet is forwarded to the next SF in the SFC by examining the metadata in the packet header. This forwarding can be done by a Service Function Forwarder (SFF) or by the SFs themselves.
Some conventional systems propose a mechanism of path optimization in dynamic service chaining by collecting information about the inter-node latency, and then trying to minimize the inter-node latency by choosing appropriate service function instances based on its location in a Service Function Path (SFP), which is an instance of an SFC, taking into consideration any pair-wise dependencies. Some conventional systems propose minimizing on inter-node delay (transmission and execution delay). However, these do not consider insertion and removal of SFs from the SFP to optimize performance and usage of network resources.
Some conventional systems propose a mechanism of dynamic and context-aware service chaining. These propose a flexible service function template containing mandatory and optional service functions, and the conditions for inclusion or exclusion of the optional service functions. These further propose a method of inclusion or removal of optional service functions based on estimated network conditions, estimated SFP performance (QoS parameters and the latency associated with the SFP) and/or based on changes in network context (for example, location of end-user(s), access-network type used for the service, or change in session characteristics).
However, these conventional systems fail to consider the impact or cost of the inclusion or exclusion of a SF in the specific SFP (called “primary SFP”). The impact may be on the performance of a set of SFPs (primary and associated SFPs). For example, if an SF instance is included in the primary SFP, it would increase the load of the SF thereby affecting the performance of the primary SFP and/or associated SFP. If an SF instance is excluded from the primary SFP, it could render the location of the SF instance (excluded from primary SFP) inappropriate for associated SFPs. It could also render the location of other SFs in the primary SFP to be inappropriate or non-optimal from the SFP performance point of view.
Additionally, the other drawback is the network resources consumption (change) for the set of SFPs. Inclusion or exclusion of a SF in the primary SFP would increase/decrease the load of the included or excluded SF. Another drawback is related to the network traffic (any destabilization, and the like) in the set of SFPs. For example, inclusion of the SF in the primary SFP may result in scaling up of the SF and/or load-balancing across different SF instances, thereby impacting associated SFPs which contain that SF due to this change (example, out of sequence packets, packet drops, throughput decrease, and the like).